1. Field of the Invention
The invention relates generally to windowing toolkits for computers.
2. Background Art
The basic functionality of a computer is dictated both by the hardware of the computer and by the type of operating system it uses. Various operating systems exist in the marketplace, including Solaris from Sun Microsystems, Inc., MacOS from Apple Computer, Inc., the “Windows” operating systems, e.g., Windows® 95/98 and Windows NT®, from Microsoft Corporation, and Linux. A given combination of computer hardware, an operating system, and a windowing system will be referred to herein as a “platform.” Prior to the popularity of the Internet, software developers wrote programs specifically designed to run on specific platforms. Thus, a program written for one platform could not be run on another. However, the advent of the Internet made cross-platform compatibility a necessity.
Prior art FIG. 1 illustrates a conceptual arrangement wherein a first computer 3 running the Solaris platform and a second computer 5 running the Windows® 98 platform are connected to a server 9 via the Internet 7. A resource provider using the server 9 might be any type of business, governmental, or educational institution. The resource provider has a need to provide its resources to both the user of the Solaris platform and the user of the Windows® 98 platform, but does not have the luxury of being able to custom-design its content for the individual platforms.
The Java™ programming language was developed by Sun Microsystems to address this problem. The Java™ programming language was designed to be simple for the programmer to use, yet to be able to run securely over a network and work on a wide range of platforms.
Prior art FIG. 2 illustrates how to create a Java™ application. In order to create a Java™ application, the developer first writes the application in human-readable Java™ source code. As used herein, the term “application” refers to both true Java™ applications and Java™ “applets,” which are essentially small applications usually embedded in a web page. In the example shown, the application “Program” 11 is created as a human-readable text file. The name of this text file is given the required extension “java ”.
A Java™ compiler 13, such as “javac” available from Sun Microsystems, Inc., is used to compile the source code into a machine-readable binary file 15. The source text file 11 will contain Java™ language commands, e.g., “import java.awt.Frame”. A discussion of the Java™ language itself is beyond the scope of this document. However, complete information regarding the Java™ programming language is available from Sun Microsystems, both in print and via the Internet at java.sun.com. The resulting binary file 15 will automatically receive the same file name as the source text file 11, but will use “.class” as the trailing extension.
The Java™ runtime environment incorporates a Java™ “virtual machine” (“JVM”) 16 to convert the “.class” byte codes into actual machine executions 17. The machine executions (like drawing windows, buttons, and user prompt fields) will occur in accordance to the application developer's code instructions. Because Sun Microsystems specifically designed the JVM to run on different platforms, a single set of “.class” byte codes will execute on any platform where a JVM has been installed. An Internet browser such as Netscape Navigator or Microsoft Internet Explorer that incorporates a JVM is called a “Java™-enabled” browser.
The cross-platform architecture of the Java™ programming language is illustrated in prior art FIG. 3, which shows how the Java™ language enables cross-platform applications over the Internet. In the figure, the Solaris platform 3 and the Windows® 98 platform 5 are each provided with a Java™ virtual machine (“JVM”) 21. The resource provider creates a Java™ application using the Java™ software development kit (“SDK”) 23 and makes the compiled Java™ byte codes available on the server 9. Through standard Internet protocols, both the computer 3 and the computer 5 may obtain a copy of the same byte codes and, despite the difference in platforms, execute the byte codes through their respective JVMs.
Typical computer applications, including most Java™ applications, provide graphical user interfaces (GUIs). A GUI consists of graphical components, such as windows, buttons, and text fields displayed on the screen. The user interacts with an application by means of the GUI, clicking on the buttons or typing text into the text fields.
Platforms, including the Java™ platform, provide the developer convenient means for writing the GUI portions of applications in the form of user interface toolkits.
Such toolkits typically include a set of pre-built graphical components (buttons, text fields, etc.) that the developer uses to build applications. The toolkits may also provide mechanisms for other functions. One such function is keeping track of which component will receive keyboard input typed by the user. Typically, at any given time, keyboard input will be directed to one special component, called the “focused component” or “focus owner”. This component may be distinguished in appearance by a highlight or a blinking caret. The user may change which component is the focused component, typically by using the mouse to click on the desired new focus owner. Many user interface toolkits will interpret such mouse clicks and respond by resetting the focus owner to the clicked-on component.
Modem platforms provide facilities for multiple graphical applications to be running at the same time, and each application may present the user with multiple windows. Therefore, a typical display will show many windows simultaneously. One of these windows will usually be distinguished, typically with a darkened title bar, as the “active window”. The active window is the window with which the user is currently interacting. It will contain the focused component, if there is one.
Prior art FIG. 4 illustrates an exemplary display on a screen 31 including windows 33, 34, and 35. Each window includes a title bar 37 for displaying the title of the window and, if applicable, a menu bar 39 containing a number of pull down menu buttons defined by the developer. In this example, window 34 is the active window, as indicated by its darkened title bar. Windows 33 and 35 are inactive as indicated by their grayed out title bars. The text field 61 in window 34 is the focus owner, as indicated by the caret (which may be blinking, to further draw the user's attention). The window 33 includes a number of typical components, including “radio buttons” 41 which in this case allow the user to select a prefix, a text field 43 for entering a name, and an address field 45 for entering an address. Component 47 is a “chooser” that allows the user to choose a state. “Check boxes” 49 allow the user to select one or all of the options that apply. Associated with these check boxes are additional radio buttons 51 and 53 that allow the user to select a desired means of transmission. If the “QUOTE” check box 49 is selected and the telephone radio button is selected, the window 34 appears allowing the user to enter telephone numbers. An additional text area 57 is associated with the “OTHER” check box 49. Finally, “SUBMIT” and “RESET” buttons 59 are provided to allow the user to either submit the form or to reset it.
The Java™ platform provides the developer with two user interface toolkits that may be used to build applications: the Abstract Windowing Toolkit, abbreviated AWT, and Swing. The AWT has a unique architecture, in that it is built on top of each platform's native toolkit and uses each platform's native components. For example, an AWT text field consists of the native toolkit's text field component, together with additional data. The underlying native component, called the “heavyweight peer,” is used to provide much of the AWT component's functionality. For example, the AWT delegates the job of painting the component on the screen to the native toolkit. In this way, the AWT can be used to build applications that, on each platform, look and behave like the platform's native applications.
Swing, by contrast, contains no heavyweight peers. Instead, its components are “lightweight,” that is, have no corresponding native components. In fact, the underlying native toolkit is unaware of Swing's components, so nearly all of the components' functionality must be provided by Swing.
When a user interacts with a computer by typing on the keyboard or clicking the mouse on different areas of the computer screen, the underlying native platform informs the appropriate application of the user's actions by means of native “events.” These events are platform-specific and contain different information depending on the action that the user performed. For example, if the user typed a key on the keyboard, the underlying platform might generate a “key pressed” event when the key was pressed and a “key released event” when the key was released. The events will contain various information about the user action, such as which key was pressed and released or the state of the keyboard (e.g., the CAPS-LOCK key) during the user's actions.
As mentioned above, the events are generated by the underlying platform and are therefore platform-specific. Different platforms will generate different events in response to the same user actions, and the events themselves will contain different information depending on the platform that generated them. Another difference between platforms may be the way in which events are delivered to the appropriate application. On some systems, events might be placed on a queue, and it is the application's responsibility to dequeue the events and process them. On other systems, the application may register a special procedure, called an “event handler,” with the underlying platform. This event handler will be called whenever the platform wishes to deliver an event to that application.
These platform differences in events and event delivery mechanisms are some of the reasons that, prior to the Java™ platform's introduction, it was impossible for developers to write applications that worked on multiple platforms without customizing the application for each platform. The Java™ user interface toolkits address this problem by providing a uniform event model for all platforms on which the Java™ platform is implemented. The Java™ implementation hides both the native delivery mechanism and the native events themselves from its applications by registering native handlers or dequeuing native events as appropriate. Then, based on the native events it receives, it generates the appropriate “Java™ events” and delivers them to its applications via a mechanism of its own (typically by calling Java™ event handlers registered by the Java™ application.)
Because different platforms generate different native events, it follows that there is not a one-to-one mapping between native events and Java™ events. Also, because native events on different platforms contain different information, in some cases platform-specific information may be omitted from a Java™ event, while in other cases information not present in a native event may need to be computed for inclusion in a Java™ event. It is the job of the Java™ implementation on each platform to unify these differences so that Java™ applications on different platforms receive the same sequence of Java™ events when exposed to the same user actions.
Referring back to prior art FIG. 4, we observe that top-level windows 33, 34, and 35 all have title bars that display each window's title and may be highlighted to indicate that the window is active. Windows that include title bars are referred to as “decorated windows.”
In addition to decorated windows, AWT defines a different kind of top-level window called an “undecorated window.” An undecorated window does not have a title bar and can never be the active window. An example of such a window is shown in prior art FIG. 5, wherein window 33 is shown as active on the screen. In addition to window 33, in response to some action by the user or programmatically, undecorated window 65 appears on the screen with, for example, a textual reminder such as “remember to connect cable.” It should be noted that undecorated window 65 does not have a title bar or other decoration and thus cannot be the active window. Although in this example the undecorated window 65 simply displays informational text to the user, numerous other applications of undecorated windows exist. For example, undecorated windows can be used as tool tips or popup menus.
On most platforms, only a descendant of the active window can be the focus owner, but Java™ undecorated windows can never be active. (Note that a descendant as referred to herein may not be proper—that is, the window itself is considered one of its descendants.) Therefore, native platforms' definitions of focus dictate that no descendant of a Java™ undecorated window could ever be the focus owner. On the other hand, AWT's definition of undecorated windows requires that their descendants be capable of receiving keystrokes. It is the responsibility of the Java™ implementation on each platform to reconcile the platform's definition of focus with the requirements of the Java™ platform.
Therefore, a need exists for a mechanism by which keystrokes can be delivered to windows that cannot be active, such as AWT's undecorated windows, without violating the native platform's definition of focus.